Data Protection

Teradata has many features to protect you against a potential data loss. Each of this features protects your data in a different way, and on a different level of granularity. Default activates some of the features; others have to be turned on explicitly.


Fallback
Fallback  protects your data by storing a second copy of each row of a table on a different AMP in the same cluster. If an AMP fails, the system accesses the Fallback rows to meet requests. You can continue using Fallback tables without losing access to data.

• Fallback provides AMP fault tolerance at the table level. 
• With Fallback tables, if one AMP fails, all of the table data is still available. 
• Users may continue to use Fallback tables without any loss of available data.
• When a table is created, or any time after its creation, the user may specify whether or not the system should keep a fallback copy. 
• If Fallback is specified, it is automatic and transparent to the user.
• Fallback guarantees that the two copies of a row will always be on different AMPs. Therefore, if either AMP fails, the alternate row copy is still available on the other AMP.
• The benefits of Fallback include protecting your data from hardware (disk) failure, protecting your data from software (node) failure.
• Automatic recovery and minimum recovery time after repairs or fixes are complete.

Note:- If there is a benefit to protecting your data. However, there are costs associated with that benefit. There is Twice the disk space for storage and twice the I/O for Inserts,Updates and Deletes.

Transient Journal 

The Transient Journal exists to permit the successful rollback of a failed transaction. Transactions are not committed to the database until an End Transaction request has been received by the AMPs, either implicitly or explicitly. Until that time, there is always the possibility that the transaction may fail in which case the participating table(s) must be restored to their pre-transaction state.​

• The Transient Journal maintains a copy of all before images of all rows affected by the transaction. 
• If the event of transaction failure, the before images are reapplied to the affected tables, the images are deleted from the journal and a rollback operation is completed. ​
• In the event of transaction success, at the point of transaction commit, the before images for the transaction are discarded from the journal.
• In Summary, if a Transaction fails (for whatever reason), the before images in the transient journal are used to return the data (in the tables involved in the transaction) to its original state.